Flow control techniques are used to prevent loss of packets in a network due to buffer overflows. Sophisticated flow control algorithms use a ‘send-me-x-packets’ model that allows the sender to exactly know how many packets to send without causing problems at the receiver. However, in many wireless networks such sophisticated flow control mechanisms do not exist. Many wireless networks (as well as other networks) use a relatively primitive ON-OFF control mechanism, which unfortunately leads to buffer overflows and subsequent packet losses.
For example, within the context of a per-flow input queue at a Base Station (BS) or eNodeB, packets are provided to the queue via a Packet Gateway (PGW) or other node which takes an incoming IP packet destined for a user, applies a Packet Data Protocol (PDP) context (including security), and fragments the packet to fit the maximum size specific to the user's context.
Within the context of ON-OFF flow control, a BS transmits toward the PGW a FlowON_i message for each specific per-flow queue, i, that has less than the ON_Threshold number of packets. Once the POW receives this control packet, the PGW starts transmitting packets toward the BS corresponding to that per-flow queue, as long as such packets can be sent from its own output buffers. Similarly, the BS transmits toward the PGW a FlowOFF_i message once the number of packets in the BS per-flow queue of queue i has more than the OFF_threshold number of packets. Once the POW receives this control packet, the PGW starts transmitting packets toward the BS corresponding to that per-flow queue.
ON-OFF flow control works well when the link delay D between the PGW and the BS is close to zero. To compensate for the real world situation where the link delay is not zero, system designers must allow for sufficient buffer space Q by setting the ON_threshold to a non-zero value such as 2*D*R (where R is either the peak service rate (Rpeak) or average service rate (Rave) of the BS queue) and the OFF_threshold to a value much less than the maximum per-flow queue of Q-B*D (where Q is the buffer size and B is the bandwidth of the link) to account for the link delay D.
Disadvantageously, a high bandwidth delay product B*D will lead to a large queue sizing, since each per-flow queue has to be at least B*D packets long. Moreover, a very large per-flow queue is very undesirable in the BS, since the packets in the queue have to be coded in a way that responds to network conditions faced by the user, and a large buffer makes it non-conducive to change the packets mid-stream.
Credit-based or window-based flow control is more efficient than ON-OFF flow control. Within the context of a credit-based flow control mechanism, the BS transmits toward the PGW a control message that identifies a specific number of packets to be transmitted by the PGW toward the BS (i.e., a specific number of credits). These credits or packets may be provided by the PGW at once or in installments and, regardless of the BS-PGW link delay, system designers will be able to architect the BS with relatively small per-flow queues.
Unfortunately, credit-based flow control cannot always be implemented due to a lack of support between both end-points (e.g., PGW and BS), since both end-points of the link have to be changed to support credit-based flow control.